开发工程师_卢刚: leff join时, on不会影响左边的条数,但是ot的条件如果匹配不上,则右边会丢失值, 这个的初衷就是要展示所有所有左边的数据,右边的条件不应该影响左边的展示,右边没有就只是右边不存在. 如果想对左边进行过滤,则条件应该放到where中,如果放到on中,该数据还是会出现,只是左边匹配不上

wang7year: 前面配的33.2，后面配的33.1，是一定要这样才行吗

北风之神c: 写得赞，博主用心了，但主要还是celery太难了。 celery对目录层级文件名称格式要求太高，只适合规划新的项目，对不规则文件夹套用难度高。 所以新手使用celery很仔细的建立文件夹名字、文件夹层级、python文件名字， 所以网上的celery博客教程虽然很多，但是并不能学会使用，因为要运行起来需要以下6个方面都掌握好，博客文字很难表达清楚或者没有写全面以下6个方面。 celery消费任务不执行或者报错NotRegistered，与很多方面有关系，如果要别人排错，至少要发以下6方面的截图， 1) 整个项目目录结构,celery的目录结构和任务函数位置，有很大影响 2) @task入参 ,用户有没有主动设置装饰器的入参 name,设置了和没设置有很大不同，建议主动设置这个名字对函数名字和所处位置依赖减小 3) celery的配置，task_queues(在3.xx叫 CELERY_QUEUES )和task_routes (在3.xx叫 task_routes) 4) celery的配置 include （在3.xx叫 CELERY_INCLUDE）或者 imports (3.xx CELERY_IMPORTS) 或者 app.autodiscover_tasks的入参 5) cmd命令行启动参数 --queues= 的值 6) 用户在启动cmd命令行时候，用户所在的文件夹。 在不规范的文件夹路径下，使用celery难度很高，一般教程都没教。 [项目文件夹目录格式不规范下的celery使用演示](https://github.com/ydf0509/celery_demo) 此国产分布式函数调度框架 https://function-scheduling-distributed-framework.readthedocs.io/zh_CN/latest/index.html ， 从用法调用难度，用户所需代码量，超高并发性能，qps控频精确程度，支持的中间件类型，任务控制方式，稳定程度等19个方面全方位超过celery，任何方面都是有过之而无不及 。

November's chopin: 我认为 arr[] 赋值方式的语法级别是很重要的一个原因，它没有 array_push 函数加载的额外开销，比如参数解析、保存进入函数前的环境信息、函数执行结束后的环境信息还原等。

qq_15792921: 能说说为什么吗？